 |
Теория. Предопределенные элементы. Основная конфигурация. и конфигурация базы данных
|
|
|
|
Теория
Предопределенные элементы
Обратите внимание, что система отмечает различными пикто- граммами обычный и предопределенный элементы справочника (см. рис. 3. 73).
Несмотря на то, что можно изменить код или наименование у обоих элементов, имя предопределенного элемента, которое мы задали в конфигураторе (Основной), остается неизменным, и в дальнейшем мы сможем обратиться к предопределенному элементу справочника по этому имени из встроенного языка.
Таким образом, на предопределенные элементы могут опираться алгоритмы работы конфигурации.
Из этого видно, в чем заключается принципиальная с точки зрения конфигурации разница между обычными и предопределенными элементами справочника.
Обычные элементы непостоянны для конфигурации. В процессе работы пользователя они могут появиться, исчезнуть. Поэтому конфигурация хоть и может отличить их друг от друга, но рассчи- тывать на них в выполнении каких-либо алгоритмов она не может в силу их непостоянства.
Предопределенные элементы, напротив, постоянны. В процессе работы пользователя они находятся всегда на своих местах и исчезнуть не могут.
То есть теоретически пользователь может их удалить, но для облег- чения задачи мы не даем пользователю прав не только на инте- рактивное удаление предопределенных элементов, но и на интерактивное удаление объектов вообще (см. занятие 22 «Список пользователей и их роли» на стр. 653).
Поэтому конфигурация может работать с ними вполне уверенно и опираться на них при отработке различных алгоритмов. По этой причине каждый из предопределенных элементов имеет уникальное имя для того, чтобы к нему можно было обратиться средствами встроенного языка.
|
|
|
Основная конфигурация
и конфигурация базы данных
До сих пор мы не углублялись в структуру системы
«1С: Предприятие», но теперь пришло время сказать об этом несколько слов.
Вспомните, с точки зрения пользователя, «программа 1С» состоит из платформы и конфигурации. Мы говорили, что в каждом конкретном случае используется одна из множества возможных конфигураций. Настало время сказать, что это не совсем так.
Почему не так? Потому что в каждой информационной базе суще- ствуют как минимум две конфигурации.
Почему не совсем так? Потому что пользователь действительно работает всегда только с одной конфигурацией. Вторая конфигу- рация предназначена для разработчика или человека, который должен
вносить изменения в конфигурацию (например, администратора базы данных). Для пользователя она «не видна».
Конфигурация, предназначенная для разработчика, называется Основная конфигурация (или просто Конфигурация – та, которую мы редактировали в конфигураторе).
Конфигурация, с которой работают пользователи, называется
Конфигурация базы данных.
Основную конфигурацию можно редактировать. Конфигурацию базы данных редактировать нельзя, можно только произвести обновление конфигурации базы данных на основе основной конфигурации.
Однако у вас может возникнуть естественный вопрос: если у нас есть две конфигурации – одна, которую можно редактировать, и другая, с которой работают пользователи, то почему же тогда основной называется редактируемая конфигурация? Ведь с точки зрения конечного продукта основной является именно конфигурация, с которой работают пользователи!
Дело в том, что в данном случае название «основная» дано с точки зрения разработчика, и это имеет глубокий практический смысл.
В общем случае информационная база «1С: Предприятия» может хранить более двух конфигураций: основную конфигурацию, конфи- гурацию базы данных и несколько конфигураций поставщиков.
|
|
|
Кроме этого, вне информационной базы может существовать хранилище. В нем находится конфигурация, предназначенная для групповой разработки.
Вне информационной базы может существовать также некоторое количество файлов конфигураций, в том числе файлы новой поставки (рис. 3. 74).
Конфигурация поставщика, находящаяся в информационной базе, содержит предыдущее состояние поставки. Возможна ситуация, когда конфигурация находится на поддержке одновременно у нескольких поставщиков, каждый из которых поддерживает только свою часть в виде отдельной конфигурации. В этом случае информационная база будет хранить несколько конфигураций поставщиков (состояние предыдущей поставки для каждого поставщика отдельно).
Файлы новой поставки могут существовать в виде файлов конфи- гураций (полная поставка) и файлов обновлений (поставка обнов- лений).
Рис. 3. 74. Структура конфигурации
Хранилище конфигурации содержит конфигурацию, предназначенную для групповой разработки. Она хранится не в виде единой конфигу- рации, а в виде отдельных объектов в разрезе версий конфигурации. Таким образом, мы можем получить из хранилища конфигурацию любой версии – для этого она «собирается» из объектов нужной версии.
Теперь представьте, что между всеми этими видами конфигураций существует возможность сравнения и обновления. В этом случае очень легко запутаться, и название Основная конфигурация как нельзя лучше отражает конечную цель всех изменений.
Теперь, возвращаясь к основной конфигурации и конфигурации базы данных, нужно заметить, что внутреннее разделение на две конфи- гурации позволяет вносить изменения, не прерывая работы пользо- вателей, потому что изменения вносятся в основную конфигурацию, с которой пользователи не работают.
Затем, когда разработчик будет уверен в том, что все изменения, которые он внес, верны, можно будет быстро произвести обновление конфигурации базы данных, используя основную конфигурацию.
Если эти изменения не затрагивают структуру базы данных (например, если не нужно изменять таблицы, если поменялся только программный код в каком-то модуле), то обновить конфигурацию
|
|
|
базы данных можно не прерывая работы пользователей. Это так называемое динамическое обновление.
Пользователи увидят изменения только после того, как перезапу- стят свое приложение. Используя метод встроенного языка Конфигу- рацияБазыДанныхИзмененаДинамически(), можно определить программно, нужно ли перезапускать приложение.
Но если изменения касаются структуры базы данных, например, добавился новый реквизит у справочника или изменился тип суще- ствующего реквизита, то тогда требуется реструктуризация базы данных и нужно завершить работу всех пользователей.
Разработчик всегда может сравнить основную конфигурацию и конфигурацию базы данных, может вернуться к исходному состоянию основной конфигурации, используя конфигурацию базы данных (если, например, совсем запутался в своих изменениях).
Таким образом, взаимодействие двух конфигураций можно предста- вить следующим образом (рис. 3. 75).
 |
Рис. 3. 75. Взаимодействие двух конфигураций
Когда разработчик работает с основной конфигурацией, система всегда подсказывает ему, отличается ли его вариант основной конфи- гурации от того, который сохранен, и отличается ли сохраненный вариант основной конфигурации от конфигурации базы данных.
Если разработчик редактирует основную конфигурацию и редакти- руемый вариант основной конфигурации отличается от того, который сохранен, в заголовке окна дерева конфигурации появляется признак модифицированности конфигурации (*), рис. 3. 76.
Рис. 3. 76. Заголовок окна дерева конфигурации
Если сохраненный вариант основной конфигурации отличается от конфигурации базы данных, в заголовке окна дерева конфигурации появляется знак отличия конфигураций (<! > ), рис. 3. 77.
Рис. 3. 77. Заголовок окна дерева конфигурации
Для сохранения основной конфигурации следует использовать команду Конфигурация } Сохранить конфигурацию, а для обновления конфигурации базы данных – команду Конфигурация } Обновить конфигурацию базы данных.
|
|
|
При выполнении команды Отладка } Начать отладку система сама сначала сохраняет основную конфигурацию, а затем производит ее сравнение с конфигурацией базы данных. Если конфигурации отли- чаются, выдается запрос на обновление конфигурации базы данных, который вы видели в предыдущих примерах.
При выполнении команды Отладка } Продолжить система после описанных выше действий предлагает еще и перезапустить прило- жение, чтобы прекратить текущий сеанс, запущенный в режиме отладки.
Таким образом, система старается облегчить жизнь разработчика и автоматизировать часто выполняемые операции.
Важным фактом является то, что именно в момент обновления конфигурации базы данных система создает (модифицирует) в базе данных те структуры хранения данных, которые мы описали в виде объектов конфигурации.
Таким образом, обычные элементы справочника пользователь добавляет в ту структуру базы данных, которую создала система на основе объекта конфигурации Справочник.
Предопределенные элементы этого справочника система добавляет в эту структуру сама, на основе того описания, которое содержится в объекте конфигурации Справочник.
Отсюда следует немаловажный факт (о котором говорилось в пред- ыдущем разделе), что если простые элементы справочника «безраз- личны» для конфигурации, то предопределенные элементы важны для нее, поскольку на них могут быть завязаны алгоритмы работы конфигурации.
| |
|
|
|
