Development

Documentation/ru_RU/book/1.0/14-Generators (diff)

You must first sign up to be able to contribute.

Changes between Version 8 and Version 9 of Documentation/ru_RU/book/1.0/14-Generators

Show
Ignore:
Author:
Sergei.Vasilyev (IP: 217.77.222.168)
Timestamp:
07/30/07 13:56:19 (10 years ago)
Comment:

a part about administration modules creation and configuration is partially translated

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/ru_RU/book/1.0/14-Generators

    v8 v9  
    99Список переведеных мной терминов: 
    1010<ul> 
    11 <li> <b>administration module</b> - <i>админка</i>. Часть веб-сайта, доступная лишь обслуживающему персоналу и предоставляющая возможности манипулирования данными;</li> 
     11<li> <b>administration</b> - <i>админка</i>. Часть веб-сайта, доступная лишь обслуживающему персоналу и предоставляющая возможности манипулирования данными;</li> 
    1212<li> <b>scaffolding</b> - <i>каркас</i>. Буквально означает "строительные леса";</li> 
    1313</ul> 
    192192-------------- 
    193193 
    194 Symfony can generate more advanced modules, still based on model class definitions from the `schema.yml` file, for the back-end of your applications. You can create an entire site administration with only generated administration modules. The examples of this section will describe administration modules added to a `backend` application. If your project doesn't have a `backend` application, create its skeleton now by calling the `init-app` task
     194Симфони может генерировать более продвинутые модули, основанные на определениях классов модели из файла `schema.yml`, для внутренних интерфейсов ваших приложений. Вы можете создать администрирование сайта, целиком используя генерируемые модули. Примеры этого раздела покажут вам модули администрирования, добавленные к приложению `backend`. Если ваш проект ещё не содержит приложения `backend`, создайте его при помощи такой команды
    195195 
    196196    > symfony init-app backend 
    197197 
    198 Administration modules interpret the model by way of a special configuration file called `generator.yml`, which can be altered to extend all the generated components and the module look and feel. Such modules benefit from the usual module mechanisms described in previous chapters (layout, validation, routing, custom configuration, autoloading, and so on). You can also override the generated action or templates, in order to integrate your own features into the generated administration, but `generator.yml` should take care of the most common requirements and restrict the use of PHP code only to the very specific. 
    199  
    200 ### Initiating an Administration Module 
    201  
    202 With symfony, you build an administration on a per-module basis. A module is generated based on a Propel object using the `propel-init-admin` task, which uses syntax similar to that used to initiate a scaffolding: 
     198Модули админки интерпретируют модель, используя специальный конфигурационный файл, называемый `generator.yml`, который может быть изменён для расширения сгенерированных компонент и интерфейса. Такие модули широко используют механизмы, описанные в предыдущих главах (обрамление(layout), валидацию, навигацию(routing), конфигурирование, автозагрузку и т.д.).  
     199Конечно, вы можете переопределить сгенерированные действия и шаблоны, что бы интегрировать ваши собственные наработки в сгенерированную админку, но использование разнообразных настроек `generator.yml` позволит вам свести использование PHP-кода к минимуму. 
     200 
     201### Иниализациация модуля админки 
     202 
     203В симфони, вы строите админку на основе модулей. Модуль генерируется на основе объекта Propel, используя команду `propel-init-admin`, которая использует синтаксис, аналогичный тому, что используется для инициации каркаса: 
    203204 
    204205    > symfony propel-init-admin backend article Article 
    205206 
    206 This call is enough to create an `article` module in the `backend` application based on the `Article` class definition, and is accessible by the following
     207Этого вызова достаточно для создания в приложении `backend` модуля `article`, основанного на определении класса `Article`, и он доступен по адресу
    207208 
    208209    http://localhost/backend.php/article 
    209210 
    210 The look and feel of a generated module, illustrated in Figures 14-5 and 14-6, is sophisticated enough to make it usable out of the box for a commercial application
    211  
    212 Рисунок 14-5 - `list` view of the `article` module in the `backend` application 
    213  
    214 ![list view of the article module in the backend application](/images/book/F1405.png "list view of the article module in the backend application") 
    215  
    216 Рисунок 14-6 - `edit` view of the `article` module in the `backend` application 
    217  
    218 ![edit view of the article module in the backend application](/images/book/F1406.png "edit view of the article module in the backend application") 
    219  
    220 The difference between the interface of the scaffolding and the one of the administration may not look significant now, but the configurability of the administration will allow you to enhance the basic layout with many additional features without a line of PHP. 
     211Внешний вид и поведение сгенерированного модуля, показанного на Рисунках 14-5 и 14-6, достаточно сложны, что бы использовать его в коммерческом приложении
     212 
     213Рисунок 14-5 - Предстваление `list` модуля `article` приложения `backend` 
     214 
     215![Предстваление list модуля article приложения backend](/images/book/F1405.png "Предстваление list модуля article приложения backend") 
     216 
     217Рисунок 14-6 - Предстваление `edit` модуля `article` приложения `backend` 
     218 
     219![Предстваление edit модуля article приложения backend](/images/book/F1406.png "Предстваление edit модуля article приложения backend") 
     220 
     221Разница между интерфейсом каркаса и интерфейсом админки еще не слишком заметна, но конфигурирование позволит вам усовершенствовать изначальное представление, добавить многие дополнительные возможности, не написав при этом ни единой строки кода PHP. 
    221222 
    222223>**NOTE** 
    223 >Administration modules can only be initiated (not generated)
    224  
    225 ### A Look at the Generated Code 
    226  
    227 The code of the Article administration module, in the `apps/backend/modules/article/` directory, is empty because it is only initiated. The best way to review the generated code of this module is to interact with it using the browser, and then check the contents of the `cache/` folder. Listing 14-4 lists the generated actions and the templates found in the cache
    228  
    229 Пример 14-4 - Generated Administration Elements, in `cache/backend/ENV/modules/article/` 
    230  
    231     // In actions/actions.class.php 
     224>Админки могут быть только инициализированы, но не сгенерированы
     225 
     226### Окинем взглядом сгененированный код 
     227 
     228Код модуля админки `Article`, расположенный в `apps/backend/modules/article/`, пуст, так как он всего лишь инициирован. Лучший способ просмотреть сгенерированный код этого модуля - это походить по его страницам в броузере, а затем посмотреть содержимое каталога `cache`. Пример 14-4 показывает список сгенерированных действий и шаблонов, найденных в кеше
     229 
     230Пример 14-4 - Сгенерированные элементы админки в `cache/backend/ENV/modules/article/` 
     231 
     232    // В файле actions/actions.class.php 
    232233    create           // Forwards to edit 
    233234    delete                // Deletes a record 
    238239    save             // Forwards to edit 
    239240 
    240     // In templates/ 
     241    // В каталоге templates/ 
    241242    _edit_actions.php 
    242243    _edit_footer.php 
    258259    listSuccess.php 
    259260 
    260 This shows that a generated administration module is composed mainly of two views, `edit` and `list`. If you have a look at the code, you will find it to be very modular, readable, and extensible
    261  
    262 ### Introducing the generator.yml Configuration File 
    263  
    264 The main difference between scaffoldings and administrations (apart from the fact that administration-generated modules don't have a `show` action) is that an administration relies on parameters found in the `generator.yml` YAML configuration file. To see the default configuration of a newly created administration module, open the `generator.yml` file, located in the `backend/modules/article/config/generator.yml` directory and reproduced in Listing 14-5
    265  
    266 Пример 14-5 - Default Generator Configuration, in `backend/modules/article/config/generator.yml` 
     261Видно, что модуль состоит в основном из двух представлений - `edit` and `list`/. Если вы посмотрите в код, то найдете его очень модульным, читабельным и расширяемым
     262 
     263### Введение в конфигурационный файл generator.yml 
     264 
     265Основное различие между каркасами и админками (кроме того, что админки не имеют действия `show`) заключается в том, что админки полагаются на параметры, заданные в файле `generator.yml`. Что бы посмотреть конфигурацию только что созданного модуля админки, откройте файл `generator.yml`, который находится в папке `backend/modules/article/config/generator.yml` (показан в Примере 14-5)
     266 
     267Пример 14-5 - Типовая сгенерированная конфигурация , в `backend/modules/article/config/generator.yml` 
    267268 
    268269    generator: 
    272273        theme:            default 
    273274 
    274 This configuration is enough to generate the basic administration. Any customization is added under the `param` key, after the `theme` line (which means that all lines added at the bottom of the `generator.yml` file must at least start with four blank spaces to be properly indented). Listing 14-6 shows a typical customized `generator.yml`. 
    275  
    276 Пример 14-6 - Typical Complete Generator Configuration 
     275Этой конфигурации достаточно для базовой админки. Параметры для кастомизации интерфейса добавляются под ключом `param`, после строки `theme` (это значит, что все строки, добавленные в конец файла `generator.yml`, должны начинаться как минимум с четырёх последовательных пробелов для правильного выравнивания). Пример 14-16 показывает измененный файл `generator.yml`. 
     276 
     277 
     278Пример 14-6 - Дополненная конфигурация генератора 
    277279 
    278280    generator: 
    310312            content:      { params: rich=true tinymce_options=height:150 } 
    311313 
    312 The following sections explain in detail all the parameters that can be used in this configuration file
    313  
    314 Generator Configuration 
     314Следующие разделы подробно объяснят все параметры, использованные в этом конфигурационном файле
     315 
     316Конфигурация генератора - Generator Configuration 
    315317----------------------- 
    316318 
    317 The generator configuration file is very powerful, allowing you to alter the generated administration in many ways. But such capabilities come with a price: The overall syntax description is long to read and learn, making this chapter one of the longest in this book. The symfony website proposes an additional resource that will help you learn this syntax: the administration generator cheat sheet, reproduced in Figure 14-7. Download it from [http://www.symfony-project.com/uploads/assets/sfAdminGeneratorRefCard.pdf](http://www.symfony-project.com/uploads/assets/sfAdminGeneratorRefCard.pdf), and keep it close to you when you read the following examples of this chapter
     319Конфигурационный файл генератора - очень мощное средство, которое позволяет изменить генерируемую админку многими способами. Полное описание его синтаксиса делает эту главу одной из наибольших в этой книге. Веб-сайт симфони предоставляет ещё один ресурс, который поможет вам изучить этот синтаксис: шпаргалку по генератору админок, воспроизведенную на рисунке 14-7. Скачайте её с [http://www.symfony-project.com/uploads/assets/sfAdminGeneratorRefCard.pdf](http://www.symfony-project.com/uploads/assets/sfAdminGeneratorRefCard.pdf), и расположите где-нибудь рядом, пока будете изучать примеры этой главы
    318320 
    319321The examples of this section will tweak the `article` administration module, as well as the `comment` administration module, based on the `Comment` class definition. Create the latter with the `propel-init-admin` task: 
    325327![The administration generator cheat sheet](/images/book/F1407.png "The administration generator cheat sheet") 
    326328 
    327 ### Fields 
    328  
    329 By default, the columns of the `list` view and the fields of the `edit` view are the columns defined in `schema.yml`. With `generator.yml`, you can choose which fields are displayed, which ones are hidden, and add fields of your own--even if they don't have a direct correspondence in the object model
    330  
    331 #### Field Settings 
    332  
    333 The administration generator creates a `field` for each column in the `schema.yml` file. Under the `fields` key, you can modify the way each field is displayed, formatted, etc. For instance, the field settings shown in Listing 14-7 define a custom label class and input type for the `title` field, and a label and a tooltip for the `content` field. The following sections will describe in detail how each parameter works
    334  
    335 Пример 14-7 - Setting a Custom Label for a Column 
     329### Поля - Fields 
     330 
     331По умолчанию, столбцы представления `list` и поля представления `edit` - это столбцы, определенные в файле `schema.yml`. При помощи конфигурации генератора, вы можете выбрать, какие поля будут показаны, какие - скрыты, и добавить свои собственные поля, даже если они не имеют прямого соответствия в объектной модели
     332 
     333#### Настройки полей - Field Settings 
     334 
     335Генератор админок создаёт поле `field` для каждого столбца, определенного в файле `schema.yml`. Под ключом `fields` вы можете изменить представление каждого поля. Например, настройки полей в Примере 14-7 определяют текст подписи поля, тип поля для ввода, класс css для вывода поля и подсказку для полей `title` и `content`. В следующих разделах будет детально описано, как работает каждый параметр
     336 
     337Пример 14-7 - Настройка различных меток для полей ввода-вывода 
    336338 
    337339    generator: 
    345347          content:        { name: Body, help: Fill in the article body } 
    346348 
    347 In addition to this default definition for all the views, you can override the field settings for a given view (`list` and `edit`), as demonstrated in Listing 14-8. 
    348  
    349 Пример 14-8 - Overriding Global Settings View per View 
     349В дополнение к типовой конфигурации для всех представлений, вы можете переопределить настройки полей для каждого представления (`list` и `edit`), как показано в Примере 14-8. 
     350 
     351Пример 14-8 - Переопределение настроек для каждого представления - Overriding Global Settings View per View 
    350352 
    351353    generator: 
    367369            content:      { name: Body of the article } 
    368370 
    369 This is a general principle: Any settings that are set for the whole module under the `fields` key can be overridden by view-specific (`list` and `edit`) areas that follow
    370  
    371 #### Adding Fields to the Display 
    372  
    373 The fields that you define in the `fields` section can be displayed, hidden, ordered, and grouped in various ways for each view. The `display` key is used for that purpose. For instance, to arrange the fields of the `comment` module, use the code of Listing 14-9. 
     371Это общий принцип: любые настройки, установленные для всего модуля под ключом `fields` могут быть переопределены для конкретных представлений
     372 
     373#### Добавление полей в представление - Adding Fields to the Display 
     374 
     375Поля, которые вы определяете в секции `fields`, могут быть показаны, скрыты, отсортированы и сгруппированы различными способами для каждого представления. Для этого используется ключ `display`. Например, что бы расставить поля модуля `comment`, используйте код Примера 14-9. 
    374376 
    375377Пример 14-9 - Choosing the Fields to Display, in `modules/comment/config/generator.yml` 
    394396            Editable:     [author, content, created_at] 
    395397 
    396 The `list` will then display three columns, as in Figure 14-8, and the `edit` form will display four fields, assembled in two groups, as in Figure 14-9. 
     398Представление `list` будет показывать три столбца, как на рисунке 14-8, а представление `edit` будет показывать четыре поля, собранных в две группы, как показано на Рисунке 14-9. 
    397399 
    398400Рисунок 14-8 - Custom column setting in the `list` view of the `comment` module 
    404406![Grouping fields in the edit view of the comment module](/images/book/F1409.png "Grouping fields in the edit view of the comment module") 
    405407 
    406 So you can use the `display` setting in two ways
    407  
    408   * To select the columns to display and the order in which they appear, put the fields in a simple array--as in the previous `list` view
    409   * To group fields, use an associative array with the group name as a key, or `NONE` for a group with no name. The value is still an array of ordered column names
     408Так что вы можете использовать настройки `display` двумя способами
     409 
     410  * Что бы указать, какие столбцы(поля) показывать и в каком порядке, внесите поля в простой массив, как показано в предыдущем представлении `list`
     411  * Что бы сгрупировать поля,  используйте ассоциативный массив с именем группы в качестве ключа, или `NONE`, что бы сформировать группу без имени. Значением по-прежнему будет упорядоченный список имён полей
    410412 
    411413>**TIP** 
    412 >By default, the primary key columns never appear in either view. 
     414>По умолчанию, первичный ключ никогда не отображается ни в каком представлении. 
     415 
    413416 
    414417#### Custom Fields 
    415418 
    416 As a matter of fact, the fields configured in `generator.yml` don't even need to correspond to actual columns defined in the schema. If the related class offers a custom getter, it can be used as a field for the `list` view; if there is a getter and/or a setter, it can also be used in the `edit` view. For instance, you can extend the `Article` model with a `getNbComments()` method similar to the one in Listing 14-10. 
    417  
    418 Пример 14-10 - Adding a Custom Getter in the Model, in `lib/model/Article.class.php` 
     419Вообще-то, поля в `generator.yml` не обязательно должны соответствовать полям, определенным в схеме. Если соответствующий класс предоставляет геттер, он может быть использован в представлении `list`; если есть геттер и/или сеттер, он может быть использован в представлении `edit`. Например, вы можете расширить модель `Article`, добавив метод `getNbComments()`, как показано в Примере 14-10. 
     420 
     421Пример 14-10 – Добавление собственного геттера в модель, `lib/model/Article.class.php` 
    419422 
    420423    [php] 
    424427    } 
    425428 
    426 Then `nb_comments` is available as a field in the generated module (notice that the getter uses a camelCase version of the field name), as in Listing 14-11
     429Теперь `nb_comments` доступна как поле в генерируемом модуле (заметьте, что геттер использует camelCase-соглашение для имени поля)
    427430 
    428431Пример 14-11 - Custom Getters Provide Additional Columns for Administration Modules, in `backend/modules/article/config/generator.yml` 
    472475#### Partial Fields 
    473476 
    474 The code located in the model must be independent from the presentation. The example of the `getArticleLink()` method earlier doesn't respect this principle of layer separation, because some view code appears in the model layer. To achieve the same goal in a correct way, you'd better put the code that outputs HTML for a custom field in a partial. Fortunately, the administration generator allows it if you declare a field name prefixed by an underscore. In that case, the `generator.yml` file of Listing 14-13 is to be modified as in Listing 14-14. 
    475  
    476 Пример 14-14 - Partials Can Be Used As Additional Columns--Use the `_` Prefix 
     477Код модели должен быть независимым от представления. Приведенный пример метода `getArticleLink()` нарушает этот принцип, потому что кусочек кода представления появился в коде модели. Что бы достичь требуемого эффекта корректным путем, вам лучше разместить код, который выводит HTML для заказного поля, в обособленном фрагменте шаблона. К счастью, генератор админок позволяет вам объявить поле, название которого начинается со знака подчеркивания. В таком случае, файл `generator.yml` из Примера 14-13 будет изменен таким образом, как показано в Примере 14-14. 
     478 
     479Пример 14-14 - Обособленные фрагменты шаблона могут использоваться как дополнительные поля с помощью префикса `_` 
    477480 
    478481        list: 
    479482          display:        [id, _article_link, created_at] 
    480483 
    481 For this to work, an `_article_link.php` partial must be created in the `modules/comment/templates/` directory, as in Listing 14-15
    482  
    483 Пример 14-15 - Example Partial for the `list` View, in `modules/comment/templates/_article_link.php` 
     484Что бы это работало, обособленный фрагмент шаблона с названием `_article_link.php`, код которого показан в Примере 14-15, должен быть создан в каталоге `modules/comment/templates/`
     485 
     486Пример 14-15 - Обособленный фрагмент шаблона для представления `list`, в файле `modules/comment/templates/_article_link.php` 
    484487 
    485488    <?php echo link_to($comment->getArticle()->getTitle(), 'article/edit?id='.$comment->getArticleId()) ?> 
    513516To change the `edit` and `list` views' appearance, you could be tempted to alter the templates. But because they are automatically generated, doing so isn't a very good idea. Instead, you should use the `generator.yml` configuration file, because it can do almost everything that you need without sacrificing modularity. 
    514517 
    515 #### Changing the View Title 
     518#### Изменение заглавия представления 
    516519 
    517520In addition to a custom set of fields, the `list` and `edit` pages can have a custom page title. For instance, if you want to customize the title of the `article` views, do as in Listing 14-18. The resulting `edit` view is illustrated in Figure 14-12. 
    574577The `list` view can display the details of a record in a tabular way, or with all the details stacked in one line. It also contains filters, pagination, and sorting features. These features can be altered by configuration, as described in the next sections. 
    575578 
    576 #### Changing the Layout 
     579#### Изменение обрамления 
    577580 
    578581By default, the hyperlink between the `list` view and the `edit` view is borne by the primary key column. If you refer back to Figure 14-11, you will see that the `id` column in the comment list not only shows the primary key of each comment, but also provides a hyperlink allowing users to access the `edit` view. 
    662665![Allowing the filtering of empty author values](/images/book/F1417.png "Allowing the filtering of empty author values") 
    663666 
    664 #### Sorting the List 
    665  
    666 In a `list` view, the table headers are hyperlinks that can be used to reorder the list, as shown in Figure 14-18. These headers are displayed both in the `tabular` and `stacked` layouts. Clicking these links reloads the page with a `sort` parameter that rearranges the list order accordingly
    667  
    668 Рисунок 14-18 - Table headers of the `list` view are sort controls 
     667#### Сортировка списка 
     668 
     669В представлении `list`, заголовки таблиц - это ссылки, которые можно использовать для сортировки списка, как показано на рисунке 14-18. Эти заголовки показываются и в табличной, и в `stacked` верстке. При нажатии этих ссылок, таблица загружается с параметром `sort`, что соотвествующим образом меняет очередность расположения данных в списке
     670 
     671Рисунок 14-18 - Заголовки столбцов таблицы в представлении `list` в качестве средств управления сортировкой 
    669672 
    670673![Table headers of the list view are sort controls](/images/book/F1418.png "Table headers of the list view are sort controls") 
    671674 
    672 You can reuse the syntax to point to a list directly sorted according to a column
     675Вы можете повторно использовать синтаксис URI, что бы получить список, отсортированный нужным образом
    673676 
    674677    [php] 
    675678    <?php echo link_to('Comment list by date', 'comment/list?sort=created_at&type=desc' ) ?> 
    676679 
    677 You can also define a default `sort` order for the `list` view directly in the `generator.yml` file. The syntax follows the example given in Listing 14-26. 
    678  
    679 Пример 14-26 - Setting a Default Sort Field in the `list` View 
     680Вы так же можете определить порядок сортировки по умолчанию в файле `generator.yml`. Синтаксис приведен в Примере 14-26. 
     681 
     682Пример 14-26 - Настройка сортировки по умолчанию для представления `list` 
    680683 
    681684        list: 
    682685          sort:   created_at 
    683           # Alternative syntax, to specify a sort order 
     686          # Альтернативный синтаксис, что бы указать направление сортировки - Alternative syntax, to specify a sort order 
    684687          sort:   [created_at, desc] 
    685688 
    686689>**NOTE** 
    687 >Only the fields that correspond to an actual column are transformed into sort controls--not the custom or partial fields
    688  
    689 #### Customizing the Pagination 
    690  
    691 The generated administration effectively deals with even large tables, because the `list` view uses pagination by default. When the actual number of rows in a table exceeds the number of maximum rows per page, pagination controls appear at the bottom of the list. For instance, Figure 14-19 shows the list of comments with six test comments in the table but a limit of five comments displayed per page. Pagination ensures a good performance, because only the displayed rows are effectively retrieved from the database, and a good usability, because even tables with millions of rows can be managed by an administration module
    692  
    693 Рисунок 14-19 - Pagination controls appear on long lists 
    694  
    695 ![Pagination controls appear on long lists](/images/book/F1419.png "Pagination controls appear on long lists") 
    696  
    697 You can customize the number of records to be displayed in each page with the `max_per_page` parameter
     690>Только поля, соответствующие реальным столбцам БД, могут быть преобразованы в элементы, управляющие сортировкой--но не заказные поля или поля, формируемые обособленным фрагментом шаблона
     691 
     692#### Управление постраничной разбивкой 
     693 
     694Сгенерированная админка эффективно работает даже с большими таблицами, потому что представление `list` изначально использует постраничную разбивку. Когда количество записей в таблице превышает максимально допустимое количество строк на странице, внизу списка появляются элементы навигации между страницами. Например, рисунок 14-19 показывает список из шести комментариев в таблице с лимитом пять комментариев для одной страницы. Постраничная разбивка обеспечивает хорошую производительность, потому что из БД извлекаются только те записи, которые отображаются. Таким образом, админка может обеспечить работу с таблицами, содержащими миллионы записей
     695 
     696Рисунок 14-19 - В длинных списках появляются элементы навигации между страницами 
     697 
     698![В длинных списках появляются элементы навигации между страницами](/images/book/F1419.png "PВ длинных списках появляются элементы навигации между страницами") 
     699 
     700Вы можете настроить количество записей, отображаемое на одной странице, при помощи параметра `max_per_page`
    698701 
    699702        list: 
    702705#### Using a Join to Speed Up Page Delivery 
    703706 
    704 By default, the administration generator uses a simple `doSelect()` to retrieve a list of records. But, if you use related objects in the list, the number of database queries required to display the list may rapidly increase. For instance, if you want to display the name of the article in a list of comments, an additional query is required for each post in the list to retrieve the related `Article` object. So you may want to force the pager to use a `doSelectJoinXXX()` method to optimize the number of queries. This can be specified with the `peer_method` parameter. 
     707По умолчанию, генератор админок использует простой `doSelect()` для получения списка записей. Но, если вы используете в списке связанные между собой объекты, количество запросов, требуемых для отображения списка, может резко увеличиться. Например, если вы желаете показать названия статей в списке комментариев, для каждого комментария потребуется отдельный запрос на получение соответствующего объекта `Article`. В этом случае, вы, возможно, предпочтете использовать запрос вида `doSelectJoinXXX()`, что бы уменьшить число запросов к БД. Это можно сделать, указав параметр `peer_method`: 
    705708 
    706709        list: 
    707710          peer_method:   doSelectJoinArticle 
    708711 
    709 Chapter 18 explains the concept of Join more extensively. 
     712Глава 18 исчерпывающе объяснит концепцию объединений таблиц (Join). 
     713>**NOTE** 
     714>Я не уверен, что при использовании mysql объединения улучшат производительность. *(Прим. перев.)* 
    710715 
    711716### Edit View-Specific Customization 
    712717 
    713 In an `edit` view, the user can modify the value of each column for a given record. Symfony determines the type of input to display according to the data type of the column. It then generates an `object_*_tag()` helper, and passes that helper the object and the property to edit. For instance, if the article `edit` view configuration stipulates that the user can edit the `title` field
     718В представлении `edit`, пользователь может модифицировать все поля выбранной записи. Симфони определяет, какого типа должен быть элемент, предназначенный для редактирования поля, основываясь на типе данных соответствующего столбца. Затем она генерирует помощник `object_*_tag()`, and passes that helper the object and the property to edit. Например, если конфигурация представления `edit` оговаривает, что пользователь может редактировать поле `title`
    714719 
    715720        edit: 
    716721          display: [title, ...] 
    717722 
    718 then the `edit` page will display a regular text input tag to edit the `title` because this column is defined as a `varchar` type in the schema
     723то страница `edit` для редактирования `title` покажет поле для ввода *текста*, потому что это поле определено в схеме как `varchar`
    719724 
    720725    [php] 
    721726    <?php echo object_input_tag($article, 'getTitle') ?> 
    722727 
    723 #### Changing the Input Type 
     728#### Изменение тега Changing the Input Type 
    724729 
    725730The default type-to-field conversion rules are as follows: 
    806811### Dealing with Foreign Keys 
    807812 
    808 If your schema defines table relationships, the generated administration modules take advantage of it and offer even more automated controls, thus greatly simplifying the relationship management. 
     813Если ваша схема определяет связи между таблицами, the generated administration modules take advantage of it and offer even more automated controls, thus greatly simplifying the relationship management. 
    809814 
    810815#### One-to-Many Relationships 
    820825Symfony also takes care of n-n table relationships, but since you can't define them in the schema, you need to add a few parameters to the `generator.yml` file. 
    821826 
    822 The implementation of many-to-many relationships requires an intermediate table. For instance, if there is an n-n relation between a `blog_article` and a `blog_author` table (an article can be written by more than one author and, obviously, an author can write more than one article), your database will always end up with a table called `blog_article_author` or similar, as in Figure 14-20. 
     827Реализация отношений "многие-ко-многим" требует промежуточной таблицы. Например, если между таблицами `blog_article` и `blog_author` существует отношение "многие-ко-многим" (статья может быть написана несколькими авторами и автор может участвовать в написании нескольких статей), ваша база данных будет содержать таблицу `blog_article_author`, или ей подобную, как показано на Рисунке 14-20. 
    823828 
    824829Рисунок 14-20 - Using a "through class" to implement many-to-many relationships 
    826831![Using a "through class" to implement many-to-many relationships](/images/book/F1420.png "Using a through class to implement many-to-many relationships") 
    827832 
    828 The model then has a class called `ArticleAuthor`, and this is the only thing that the administration generator needs--but you have to pass it as a `through_class` parameter of the field
    829  
    830 For instance, in a generated module based on the `Article` class, you can add a field to create new n-n associations with the `Author` class if you write `generator.yml` as in Listing 14-30. 
    831  
    832 Пример 14-30 - Handling Many-to-Many Relationships with a `through_class` Parameter 
     833При этом, модель будет содержать класс `ArticleAuthor`, и это всё, что нужно генератору админок, но вы должны передать его как параметр `through_class`
     834 
     835Например, в генерируемом модуле, основанном на классе `Article`, вы можете добавить поле, предназначенное для создания новых связей "многие-ко-многим" с классом `Author`, если вы опишите его в файле `generator.yml` так, как показано в Примере 14-30. 
     836 
     837Пример 14-30 - Поддержка отношения многие-ко-многим при помощи параметра `through_class` 
    833838 
    834839        edit: 
    921926          actions:        {} 
    922927 
    923 ### Form Validation 
    924  
     928### Проверка данных, передаваемых через формы 
     929 
     930Если вы посмотрите на сгенерированный шаблон `_edit_form.php` в каталоге `cache/` вашего проекта, вы увидите, что поля форм используют специальное соглашение о наименовании. В генерируемом представлении `edit`, имена полей ввода являются результатом соединения имени-с-подчеркиваниями класса модели и имени поля в квадратных скобках. 
    925931If you take a look at the generated `_edit_form.php` template in your project `cache/` directory, you will see that the form fields use a special naming convention. In a generated `edit` view, the input names result from the concatenation of the underscore-syntaxed model class name and the field name between angle brackets. 
    926932 
    927 For instance, if the `edit` view for the `Article` class has a `title` field, the template will look like Listing 14-35 and the field will be identified as `article[title]`. 
    928  
    929 Пример 14-35 - Syntax of the Generated Input Names 
     933Например, если представление `edit` класса `Article` содержит поле `title`, поле будет обозначено как `article[title]`. 
     934 
     935Пример 14-35 - Синтаксис генерируемых имен полей ввода 
    930936 
    931937    // generator.yml 
    946952This has plenty of advantages during the internal form-handling process. However, as explained in Chapter 10, it makes the form validation configuration a bit trickier, so you have to change square brackets, `[` `]`, to curly braces, `{` `}`, in the `fields` definition. Also, when using a field name as a parameter for a validator, you should use the name as it appears in the generated HTML code (that is, with the square brackets, but between quotes). Refer to Listing 14-36 for a detail of the special validator syntax for generated forms. 
    947953 
    948 Пример 14-36 - Validator File Syntax for Administration-Generated Forms 
    949  
    950     ## Replace square brackets by curly brackets in the fields list 
    951     fields: 
     954Пример 14-36 - Синаксис файла валидации для генерируемых форм админок 
     955 
     956    ## В списке полей, замените квадратные скобки круглыми 
    952957      article{title}: 
    953958        required: 
    954959          msg: You must provide a title 
    955         ## For validator parameters, use the original field name between quotes 
     960        ## Для параметров валидатора используйте название поля, заключенное в кавычки 
    956961        sfCompareValidator: 
    957962          check:        "user[newpassword]" 
    982987            addcomment:   { credentials: [admin], name: Add a comment, action: addComment, icon: backend/addcomment.png } 
    983988 
    984 Modifying the Presentation of Generated Modules 
     989Изменение представления генерируемых модулей 
    985990----------------------------------------------- 
    986991 
    987992You can modify the presentation of the generated modules so that it matches any existing graphical charter, not only by applying your own style sheet, but also by overriding the default templates. 
    988993 
    989 ### Using a Custom Style Sheet 
     994### Использование своей таблицы стилей 
    990995 
    991996Since the generated HTML is structured content, you can do pretty much anything you like with the presentation. 
    10421047### Customizing the Theme 
    10431048 
    1044 There are other partials inherited from the framework that can be overridden in the module `templates/` folder to match your custom requirements
    1045  
    1046 The generator templates are cut into small parts that can be overridden independently, and the actions can also be changed one by one
    1047  
    1048 However, if you want to override those for several modules in the same way, you should probably create a reusable theme. A theme is a complete set of templates and actions that can be used by an administration module if specified in the theme value at the beginning of `generator.yml`. With the default theme, symfony uses the files defined in `$sf_symfony_data_dir/generator/sfPropelAdmin/default/`. 
    1049  
    1050 The theme files must be located in a project tree structure, in a `data/generator/sfPropelAdmin/[theme_name]/template/` directory, and you can bootstrap a new theme by copying the files from the default theme (located in `$sf_symfony_data_dir/generator/sfPropelAdmin/default/template/` directory). This way, you are sure that all the files required for a theme will be present in your custom theme: 
    1051  
    1052     // Partials, in [theme_name]/template/templates/ 
     1049Что бы удовлетворить ваши требования, в папке `templates/` модуля можно переопределить другие обособленные фрагменты шаблонов, унаследованные от фреймворка
     1050 
     1051Сгенерированные шаблоны разбиты на маленькие кусочки, которые могут быть переопределены независимо друг от друга, и действия так же могут быть изменены одно за другим
     1052 
     1053Однако, если вы хотите переопределить их для нескольких модулей одинаковым способом, возможно, вам следует создать повторно используемую _тему_. Тема - это набор шаблонов и действий, которые могут быть использованы в модуле админки при помощи указания значения `theme` в начале файла `generator.yml`. С темой по умолчанию, симфони использует файлы, находящиеся в каталоге `$sf_symfony_data_dir/generator/sfPropelAdmin/default/`. 
     1054 
     1055Файлы темы должны быть расположены внутри проекта, в каталоге `data/generator/sfPropelAdmin/[theme_name]/template/` directory, и вы можете начать создание новой темы, скопировав файлы из темы по умолчанию. Таким образом, вы можете быть уверены, что все файлы, необходимые для темы, будут присутствовать в вашей теме. 
     1056 
     1057    // Обособленные фрагменты шаблонов, в [theme_name]/template/templates/ 
    10531058    _edit_actions.php 
    10541059    _edit_footer.php 
    10681073    _list_th_tabular.php 
    10691074 
    1070     // Actions, in [theme_name]/template/actions/actions.class.php 
    1071     processFilters()     // Process the request filters 
    1072     addFiltersCriteria() // Adds a filter to the Criteria object 
     1075    // Действия, в [theme_name]/template/actions/actions.class.php 
     1076    processFilters()     // Обработка фильтров запроса 
     1077    addFiltersCriteria() // Добавляет фильтр к объекту `Criteria` 
    10731078    processSort() 
    10741079    addSortCriteria() 
    10751080 
    1076 Be aware that the template files are actually templates of templates, that is, PHP files that will be parsed by a special utility to generate templates based on generator settings (this is called the compilation phase). The generated templates must still contain PHP code to be executed during actual browsing, so the templates of templates use an alternative syntax to keep PHP code unexecuted for the first pass. Listing 14-40 shows an extract of a default template of template
    1077  
    1078 Пример 14-40 - Syntax of Templates of Templates 
     1081Обратите внимание на то, что файлы шаблонов - это фактически шаблоны шаблонов, то есть, PHP-файлы, которые будут обработаны специальной утилитой, что бы сгенерировать шаблоны, основанные на настройках генератора (это называется фазой компиляции). Сгенерированные шаблоны по-прежнему должны содержать PHP-код, который выполняется при веб-серфинге, так что шаблоны шаблонов используют альтернативный синтаксис, что бы PHP-код не был выполнен при первом проходе. Пример 14-40 показывает содержимое типичного шаблона шаблонов
     1082 
     1083Пример 14-40 - Синтаксис шаблона шаблонов 
    10791084 
    10801085    [php] 
    10831088    <?php endforeach; ?> 
    10841089 
    1085 In this listing, the PHP code introduced by `<?` is executed immediately (at compilation), the one introduced by `[?` is only executed at execution, but the templating engine finally transforms the `[?` tags into `<?` tags so that the resulting template looks like this
     1090В этом примере, код, начинающийся с `<?` исполняется на этапе компиляции, а код, начинающийся с `[?`, выполняется при обращении к странице, а движок шаблонов преобразует теги `[?` в `<?`, так что окончательный шаблон будет выглядеть так
    10861091 
    10871092    [php] 
    10911096 
    10921097>**TIP** 
    1093 >You can also package a generator theme in a plug-in, which makes it even more reusable and easy to deploy across multiple applications. Refer to Chapter 17 for more information. 
     1098>Вы так же можете запаковать тему для генератора в плагин, после чего её можно легко внедрять в различные приложения. (См. Главу 17.) 
    10941099 
    10951100- 
    10961101 
    10971102>**SIDEBAR** 
    1098 >Building Your Own Generator 
     1103>Создание собственного генератора 
    10991104> 
    1100 >The scaffolding and administration generators both use a set of symfony internal components that automate the creation of generated actions and templates in the cache, the use of themes, and the parsing of templates of templates. 
     1105>Генераторы каркасов и админок используют набор внутренних компонентов симфони, которые автоматизируют создание действий и шаблонов, использование тем, обработку шаблонов шаблонов.themes, and the parsing of templates of templates. 
    11011106> 
    11021107>This means that symfony provides all the tools to build your own generator, which can look like the existing ones or be completely different. The generation of a module is managed by the `generate()` method of the `sfGeneratorManager` class. For instance, to generate an administration, symfony calls the following internally: 
    11111116------- 
    11121117 
    1113 To bootstrap your modules or automatically generate your back-end applications, the basis is a well-defined schema and object model. You can modify the PHP code of scaffoldings, but administration-generated modules are to be modified mostly through configuration
     1118Основой каркасов ваших модулей и автоматически генерируемых приложений является хорошо продуманная схема данных и объектная модель. Вы можете модифицировать PHP-код каркасов, а генерируемые модули изменяются, в основном, через изменения в конфигурации
    11141119 
    11151120The `generator.yml` file is the heart of the programming of generated back-ends. It allows for the complete customization of content, features, and the look and feel of the `list` and `edit` views. You can manage field labels, tooltips, filters, sort order, page size, input type, foreign relationships, custom interactions, and credentials directly in YAML, without a single line of PHP code. 
    11161121 
    11171122If the administration generator doesn't natively support the feature you need, the partial fields and the ability to override actions provide complete extensibility. Plus, you can reuse your adaptations to the administration generator mechanisms thanks to the theme mechanisms. 
    1118  
    1119  
    11201123}}}